home *** CD-ROM | disk | FTP | other *** search
/ Aminet 15 / Aminet 15 - Nov 1996.iso / Aminet / dev / misc / trackdisk64.lha / trackdisk64.txt < prev   
Encoding:
Text File  |  1996-09-14  |  6.7 KB  |  168 lines
  1. Supporting large direct-access block devices using
  2. 64-bit extensions to the trackdisk.device command set
  3.  
  4. Ralph Babel <rbabel@babylon.pfm-mainz.de>
  5.  
  6. [This proposal is supported by Dan Babcock <danb@tiac.net>,
  7. Randell Jesup <jesup@scala.scala.com>, Oliver Kastl
  8. <100447.3361@compuserve.com>, Bernhard Möllemann
  9. <zza@mhystic.hall.sub.org>, and Ralph Schmidt
  10. <laire@popmail.owl.de>. They all helped tremendously to
  11. improve the original draft.]
  12.  
  13. 15 April 1996
  14.  
  15. In an effort to overcome the 4-GB limit imposed by the
  16. current trackdisk.device interface (which all drivers for
  17. direct-access block devices must support in order to be
  18. compatible with the standard Amiga disk filesystem), the
  19. following set of 64-bit commands has been defined:
  20.  
  21. - new commands:
  22.  
  23.   +------------+-------------+
  24.   |command name|decimal value|
  25.   +------------+-------------+
  26.   |TD_READ64   |     24      |
  27.   |TD_WRITE64  |     25      |
  28.   |TD_SEEK64   |     26      |
  29.   |TD_FORMAT64 |     27      |
  30.   +------------+-------------+
  31.  
  32.   TD_FORMAT64 is provided mostly for reasons of symmetry, as
  33.   track-oriented formatting is required by very few devices
  34.   only (e.g. trackdisk.device), and writing a full "track"
  35.   of data using CMD_WRITE or TD_WRITE64 should not really
  36.   depend on the previous contents of that track. TD_FORMAT64
  37.   is therefore expected to be identical to TD_WRITE64 in
  38.   most implementations.
  39.  
  40. - data offset:
  41.  
  42.   Unlike CMD_READ, CMD_WRITE, TD_SEEK, and TD_FORMAT, all of
  43.   which deal with a 32-bit-wide byte offset passed via
  44.   io_Offset, the new commands listed above accept a
  45.   64-bit-wide byte offset to address the medium. The lower
  46.   32 bits of that byte offset are stored in io_Offset; the
  47.   upper 32 bits are stored in the io_Actual field, for which
  48.   the alias io_HighOffset is introduced.
  49.  
  50.   According to the 1.3 edition of the RKRM Libraries &
  51.   Devices, page 291, a driver may overwrite parameter fields
  52.   of an I/O request (other than io_Command) in the course of
  53.   processing a command, so all fields need to be
  54.   reinitialized upon every command submitted to the driver.
  55.   io_HighOffset thus does not differ from io_Offset in that
  56.   regard.
  57.  
  58.   This way, the io_HighOffset field will not overlap with
  59.   any of the extra IOExtTD fields required for the ETD-style
  60.   trackdisk.device commands, and applications can continue
  61.   to use the original IOStdReq-sized structure.
  62.   Device-driver programmers are free to implement the
  63.   TDF_EXTCOM variants of the new 64-bit commands.
  64.  
  65.   Note: it is perfectly legal for a 64-bit request to cross
  66.   a 4-GB "boundary" (i.e. io_Offset + io_Length > 2^32) or
  67.   for it to be in 32-bit space completely (i.e.
  68.   io_HighOffset == 0 && io_Offset + io_Length <= 2^32).
  69.  
  70. - transfer length:
  71.  
  72.   io_Length and io_Actual remain 32-bit quantities, and the
  73.   maximum transfer length is thus still "limited" to 2^32-1
  74.   bytes. With the Amiga's 32-bit address space, this is not
  75.   a restriction.
  76.  
  77. - old commands:
  78.  
  79.   It is considered an error to use the original 32-bit
  80.   commands CMD_READ, CMD_WRITE, and TD_FORMAT to access data
  81.   outside a unit's lower 4-GB data area by "crossing" the
  82.   upper border of the 32-bit space, i.e. io_Offset plus
  83.   io_Length _must_ be less than or equal to 2^32. Drivers
  84.   are free to reject such commands, to "wrap around" to the
  85.   beginning (offset 0) of the unit's data area, or to handle
  86.   them as 64-bit commands with io_HighOffset implicitly set
  87.   to zero.
  88.  
  89.   It is therefore recommended that filesystem-level
  90.   applications use the new 64-bit commands consistently for
  91.   all accesses to the underlying medium if part of a
  92.   partition is located outside the data area addressable by
  93.   the original 32-bit command set. This avoids checks at
  94.   run-time whether a request extends beyond the 32-bit
  95.   space.
  96.  
  97. - compatibility issues:
  98.  
  99.   Although Commodore-Amiga extended the trackdisk.device
  100.   command set twice before (OS 1.0: original command set up
  101.   to TD_PROTSTATUS; OS 1.2: up to TD_REMCHANGEINT; OS 2.0:
  102.   up to TD_EJECT), it is expected that some drivers do not
  103.   conform to the standard and provide private commands
  104.   starting at TD_LASTCOMM or simply crash the system upon
  105.   receipt of an "out-of-range" command (cf. RKRM Libraries,
  106.   3rd edition, page 924).
  107.  
  108.   Therefore, the new 64-bit commands should be sent to a
  109.   driver if and only if the associated partition they refer
  110.   to extends beyond the first 4 GB of a unit. This way, a
  111.   potentially incompatible driver will never receive any of
  112.   the new commands, and users may safely replace older
  113.   32-bit filesystems by 64-bit-compatible updates thereof in
  114.   existing configurations. Once a filesystem-level
  115.   application has determined that accessing a partition
  116.   requires the use of 64-bit commands,(*) it may optionally
  117.   check whether the underlying driver actually supports them
  118.   by issuing a TD_READ64 request with io_Offset,
  119.   io_HighOffset, and io_Length all set to zero; if the
  120.   underlying driver returns IOERR_NOCMD, the
  121.   filesystem-level application should report an error (e.g.
  122.   fail the start-up packet in case of a filesystem). For
  123.   reasons of efficiency, this check should be performed only
  124.   _once_ upon start-up.
  125.  
  126.   (*) (de_HighCyl + 1) * de_Surfaces * de_BlocksPerTrack *
  127.       de_SizeBlock * 4 > 2^32, i.e. the partition does not
  128.       reside completely in 32-bit space.
  129.  
  130.   In deference to older drivers that interpret the new
  131.   command values differently, 64-bit partitions should not
  132.   be mounted (be that via a MountList or an RDB entry) on
  133.   drivers that do not support devices larger than 4 GB. This
  134.   is no different from the current situation, where most
  135.   filesystems and drivers will simply "wrap around" and
  136.   overwrite data in the first 4-GB chunk if a partition
  137.   extending beyond the first 4 GB of a unit is mounted and
  138.   written to. This proposal does not intend to address this
  139.   issue, but neither does it prevent future standards that
  140.   may allow the caller to identify type and supported
  141.   features of a device driver.
  142.  
  143. - alternatives:
  144.  
  145.   If a driver does not implement the 64-bit commands defined
  146.   by this proposal, HD_SCSICMD may be used instead to
  147.   address data above the lower 4-GB range.
  148.  
  149. - future extensions:
  150.  
  151.   Implementors of drivers and filesystem-level applications
  152.   are free to agree on methods to determine whether a driver
  153.   is at all trackdisk.device-compatible and whether it
  154.   actually supports the 64-bit command set.
  155.  
  156. Besides drivers and filesystems, software that needs to be
  157. updated to support the extended command set includes Format,
  158. DiskCopy, disk-salvage programs, disk editors, and disk
  159. reorganizers.
  160.  
  161. Applications above the filesystem layer, in particular those
  162. that make use of the fields id_NumBlocks, id_NumBlocksUsed,
  163. and id_BytesPerBlock, may need to be enhanced to be prepared
  164. for partitions larger than 4 GB (this includes the CLI
  165. command Info).
  166.  
  167. Copyright © 1996 Ralph Babel - all rights reserved.
  168.